Modules operating on computer systems typically require access to shared resources. As examples, an application launched by an operating system may require access to files that are maintained by a file system, or the application may require access to network connections maintained by a network driver. Network drivers may require access to information structures maintained by a network packet classifier. This is a complex arrangement that includes numerous software modules, such as software drivers requiring access to many shared resources and an access supervisor that either maintains the resources or at least intercedes when a software module attempts to access a resource.
Intercession by an access supervisor is important for several reasons. For instance, when a first software module deletes a resource, other software modules that maintain direct pointers to the resource are unable to access or use the resource because their pointers no longer point to a valid resource. One solution to this problem is notifying software modules when a resource deletion occurs. However, this proposed solution requires detailed accounting and tracking of software modules and their respective pointers to the resources.
Another solution to this problem involves having an access supervisor intervene when a software module requires access to a particular resource. Such intervention ensures that a particular resource still exists before the software module is granted access to the particular resource. Typically, such intervention is accomplished by the access supervisor issuing a handle to each software module for a particular resource instead of allowing each software module a direct pointer to that particular resource.
A handle is associated with a resource and is used to refer to a particular resource when it is desired to be used by a software module. The software module does not use the handle to directly access the resource. Rather, the software module makes requests to the access supervisor for operations to be performed on the resource. The handle is presented as part of these requests to identify the resource that should be operated on. Further, multiple threads of a single program may request that operations be performed on the same resource by specifying the same handle to the access supervisor.
Handle administration systems are typically characterized by having handles that can assume either an allocated state or an unallocated state.
When a handle is in the allocated state, the access supervisor has associated that handle with a resource. The handle can then be used by a software module when the software module desires to perform an operation on the resource. To perform an operation on the resource, the software module makes a request to the access supervisor for a given operation and provides the handle to identify the resource on which the operation is to be performed. The access supervisor then checks to determine whether the handle is valid. If the handle is valid, then the operation may be performed. If the handle is not valid, then an appropriate notification to the software module may be generated.
When a handle is in the unallocated state, it is not associated with any resource and thus cannot be used to access a resource. A handle is in the unallocated state if it is never allocated or when it is “released.” A handle can be released by the software module that allocated it from the access supervisor. Releasing a handle means that the handle is no longer being used to access the resource with which it was formerly associated. Once a handle is released, it is available to be associated with another resource and thereby returned to the allocated state.
However, handles are not always released properly, and the consequences of an improper handle release can be quite costly in terms of performance and security. For example, a thread that opens a file may simply fail to close the file, resulting in a handle pointing to the file being leaked. Or, when a thread is terminated, a handle may fail to be released and the corresponding resource, to which the handle refers, may be leaked. Handle leaks like these can compromise program and overall computer performance over time, or simply cause a program to stop working.
Program security may further be compromised due to the eagerness by which handles are re-allocated. Such deficiencies are illustrated by the following example scenario in which Threads A and B concurrently execute semi-trusted code that requires access to the same publicly available file. Thread A may be assigned handle value X for the file, but execution of the semi-trusted code may switch to a different thread before a read operation is performed on the file. Thread B may then also use handle X for the same file, either maliciously or as a programming bug, perform a read operation on the file, close the file, and properly release handle X. Because handles are scarce resources, the access supervisor may soon thereafter allocate handle X to a Thread C, which executes fully trusted code. However, when Thread C reopens handle X, handle X may point to a completely different file. Therefore, when Thread A is re-started still using handle X, Thread A has access to the file intended for Thread C. Thus, thread management with semi-trusted code may result in security vulnerabilities in a multithreaded environment.